home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
SGI Developer Toolbox 6.1
/
SGI Developer Toolbox 6.1 - Disc 4.iso
/
FAQs
/
SGIfaqs
/
Dwarf-faq
< prev
next >
Wrap
Text File
|
1994-08-01
|
8KB
|
212 lines
~4Dgifts/toolbox/FAQs/SGIfaqs Dwarf-faq
DWARF is a binary debugging-information format.
The TFP compilers will produce debugging information in this format
rather than the format used in sherwood and earlier releases.
Only people *writing* compilers, debuggers, or related tools
are affected directly by this change.
These are the current DWARF topics:
1) What is DWARF
2) When will it appear
3) Documentation on DWARF
4) An Overview of DWARF Information Content
5) Can I Send This To My Friends?
6) Have a question about DWARF? *let us know*...
Last revised: $Date: 1994/01/04 18:19:16 $
1) What is DWARF
DWARF is a binary debugging-information-format. It defines, in detail,
a way for compilers to tell debuggers about source programs.
The 'final' specification of DWARF was approved by a committee of
(self-appointed) interested parties from a variety of companies in
March, 1993 by representatives from: Sun Microsystems, IBM, Motorola
Inc, Intel, UNIX System Laboratories, Inc, Data General Corp, Digital
Equipment Corporation, Ron Guilmette Computing, Eager Consulting, HAL
Computer Systems, Silicon Graphics
The committee is operating with support from UNIX International, the
body which will publish the DWARF specification. However this support
does not restrict anyone: Anyone may use the specification in any way,
royalty-free.
DWARF1 is the DWARF produced by USL's SVR4 compilers and used by their
debuggers. It is no more capable than the MIPS mdebug symbol table
and is less dense than mdebug. We will not use DWARF1.
SGI will be using DWARF 2. It is capable of recording much more
detailed information than DWARF 1 and is far more compact (debugging
information in DWARF2 format takes much less space on disk than
debugging information in DWARF1 format).
There are several reasons to change to this format (from MIPS mdebug,
which we use in all IRIX compiler releases so far, including sherwood).
De-facto standard
The intent and hope (of the committee members) is that the language
will become a de-facto-standard for debugging information.
Note that a group of companies using Intel chips recently announced
joint 'support' for this. Meaning that the PC companies will have
at least some support in their debuggers and compilers.
The GNU compilers (gcc, g++) now emit dwarf information on
many platforms.
Handles many languages
The initial report defines facilities to handle C, C++, Fortran(77
and 90) Pascal, and Modula 2.
Extensible
The report provides for extending DWARF. It guarantees to those doing
the extensions that future DWARF reports will not use certain
ranges of binary codes, thus guaranteeing that an extension
developed today will not be confused with future standard DWARF
features.
Flexible
DWARF2 already provides means to describe such things as
arbitrary C #includes, C macros, C++ classes, C++ templates,
C++ exceptions, and Fortran COMMON (among other things).
The result is that a debugger can, if it chooses, report accurately
to the debugger-user.
Extension facilities in DWARF make it possible to add sgi-specific
information into DWARF in future releases without breaking any
already-released DWARF-reading debuggers.
2) When will it appear
Work began in March, 1993. Proposals on the functional interface
that compiler-writers and debugger-writers should use are listed in
the documentation section (faq dwarf 3).
Working versions of DWARF libraries for producing and
consuming DWARF information are part of the ragnarok
compilers (compilers v4.00)
3) Documentation on DWARF
THE FOLLOWING FILES ARE IN toolbox/documents/Dwarf
DWARF version 2 industry draft: dwarf.v2.0.ps
An index : dwarf.v2.0.indx.ps
A document proposing libdwarf consumer Application Programmer
Interface (API) for DWARF VERSION 2.
Anyone writing a program which wants to read symbolic debugging
information from an object file would want to read this document.
Debugger writers (and those considering writing a debugger) will
want to read this document.
About 60 pages --> libdwarf2.1.ps
An postscript document proposing libdwarf producer Application
Programmer Interface (API) for DWARF VERSION 2.
Compiler writers will want to read this document.
About 20 pages --> libdwarf2p.1.ps
Header files for dwarf and libdwarf.
lp /hosts/quasar.mti/d/public/d/public/dwarf.h
lp /hosts/quasar.mti/d/public/d/public/libdwarf.h
4) An Overview of Dwarf Information Content
The documents mentioned in section 3 are long on details and short
on overview. Lets try to put this all in to a total picture.
To represent Debugging Information in an a.out we need several quite
different categories of information spread across various
ELF object file sections.
A. Information about code and data variables.
DWARF information is a tree of Debugging Information Entries (DIEs).
Each tree entry (Die) has a TAG which identifies what type
of entry it is and Attributes which give the details.
DIEs at the global level in a compilation unit are tied together
with Sibling Pointers.
Siblings are equal-level DIEs.
Children, on the other hand, are *owned* DIEs.
Lets adopt the following symbols for DIE relationships:
Sibling pointer ->
Child pointer |
v
Here is a representation of the DIEs for t.c where types are
left out to keep things simple (they don't change this, they
are just more DIEs to clutter things up):
t.c:
int foo(int i, int j) { return 3;}
int goo;
Compilation_Unit
|
v
function "foo" -> global variable "goo "
|
v
parameter "i" -> parameter "j"
This goes in the .debug_info section with a tiny amount
of supporting data in .debug_abbrev
B. Information about the mapping from code addresses to source
A separate section holds a very compact mapping from
code addresses to source lines (and columns).
This is in the .debug_line section.
C. Information about C Macros
If desired, all C Macro #defines and #undef-s and
#includes are recorded, with
the mapping back to the source files.
This is in the .debug_macinfo section.
D. Information about unwinding stack frames
This is specially recorded in a section of its own: a seperate
small string of bytes per function/procedure.
This is in the .debug_frame section.
Other .debug_* sections are for supporting data or for fast access to
global names, types, and statics.
6) Can I Send This To My Friends?
dwarf.v2.0.ps and dwarf.v2.0.indx.ps
Yes. These are the UI PLSIG committee industry review drafts.
The other documents are sgi-specific at this time.
The producer and consumer documents require more work, BTW.
Personally, I think these should be distributable.
No one has hinted otherwise so far.
I hope to post them to the UI PLSIG committe as proposed
standards in 1994. Or, rather, as starting points for
producer and consumer interface standards. [davea]
6) Have a question about DWARF? *let us know*...
We don't have any frequent questions yet :-)
Send your question(s) on DWARF to
davea@sgi.com
The ragnarok compilers for TFP use dwarf as their debugging-information
format.